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(57) Abstract 

The invention provides NFS 
a method" and system for 
enforcing file access control 
among client devices using 
multiple diverse access 
control models and multiple 
diverse file server protocols. 
A multi-protocol file server 
identifies each file with one 
particular access control 
model out of a plurality 
of possible models, and 
enforces that one particular 
model for all accesses to that 
file. When the file server 
receives a file server request 
for that file using a different 
access control model, the file 
server translates the access 
control limits for that file 
into no-less-restrictive limits 
in the different model. The 
file server restricts access 
by the client device using 
the translated access control 

limits. Each file is assigned CIFS 
the access control model of 
the user who created the file 

or who last set access control limits for the file. When a user having a different access control model sets access control limits, the access 
control model for the file is changed to the new model. Files are organized in a tree hierarchy, in which each tree is limited to one or 
more access control models (which can limit the ability of users to set access control limits for files in that tree). Each tree can be limited 
to NT-model-only format, Unix-model-only format, or mixed NT-or-Unix-models format. 
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Title of the Invention 
File Access Control in a Multi -protocol File Server 

5 

Background of the Invention 

/. Field of the Invention 
10 The invention relates to file access control in a multi-protocol file server. 

2. Related Art 

In an integrated computer network, it is desirable for multiple client de- 
15 vices to share access to the same files. One known method is to provide a network file 
server for storing files, capable of receiving and responding to file server requests from 
those client devices. These file server requests are made using a file server protocol, 
which is recognized and adhered to by both the file server and the client device. Because 
the files are stored at the file server, multiple client devices have the opportunity to share 
20 access to the same files. 



In a file system intended for use by more than one user, it is desirable to 
restrict access by programs to files in the file system. Restricting access includes at least 
the aspects of (1) user authentication — determining that requesting users are truly who 
25 they say they are, and (2) access control validation — determining that an authenticated 
user is allowed to access a particular file in a particular way. When the file system is 
maintained on a file server remote from the user making the request, there is an addi- 
tional aspect of the access control protocol — what requests can be made by the user to 
access files or to set access control for files. 

30 

One problem in the known art is that there are multiple diverse models for 

access control validation, each typically associated with a particular file system, and 

1 



BNSDOCID: <WO 9945456 A 1 I > 



WO 99/45456 PCT/US99/04550 

there are multiple diverse access control protocols, each typically corresponding to a 
model for access control validation. Despite the differences between these models and 
protocols, the file server should respond to file server requests from each user, and 
should exhibit access control validation behavior, consistent with each user's model and 
5 without security violations or surprises for users. 

For example, a first access control model in common use is associated with 
the Unix operating system (or a variant thereof). This first access control model associ- 
ates permissions with each file for a file owner, an owner's group, and all other users. 

10 These permissions allow access (for the owner, group, or all other users) to read, write, 
or execute the indicated file. This first access control model is typically implemented by 
the NFS ("Network File System") file server protocol, possibly augmented with an ad- 
junct file-locking protocol, NLM ("Network Lock Manager"). A second access control 
model in common use is associated with the Windows NT operating system. This sec- 

15 ond access control model associates an ACL (access control list) with each file, each en- 
try in the ACL specifying an individual user, a group of users, or all users. Each entry 
can allow access (for the specified users) to read, write, or execute the indicated file, or 
can specifically deny access. This second access control model is typically implemented 
by the CIFS ("Common Internet File System") protocol. However, NT devices can also 

20 use the NFS protocol by means of the "PC NFS" implementation, and Unix devices can 
also manipulate POSIX ACLs. These two access control models in common use differ in 
significant ways, including (1) what permissions can be assigned to a file, (2) with what 
granularity of specificity permissions can be assigned, and (3) how users are identified so 
as to match them with permissions. 

25 

One method known in the ait is to provide a multi-protocol file server that 
maps all security semantics to that of a single native operating system for the file server, 
and uses that single native operating system to validate file access control. The "Samba" 
system and similar emulation packages are believed to use this known method. This 
30 known method has the drawback that it can result in security errors or surprises for those 
client devices using security semantics other than the file server's native operating sys- 
tem. 

2 
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Another method known in the art is to provide a multi -protocol file server 
that supports differing types of security semantics for differing files, but attempts to vali- 
date file access control for each user using the user's access control model. Some "Net- 
5 ware" products available from Novell Corporation are believed to use this known 
method. This known method has the drawback that the user's access control model can 
differ significantly from the access control model set for the file, resulting in security er- 
rors or surprises for those client devices using security semantics other than associated 
with the target file. 

10 

Accordingly, it would be desirable to provide a method and system for en- 
forcing file security semantics among client devices using multiple diverse access control 
models and multiple diverse file server protocols. This advantage is achieved in an em- 
bodiment of the invention in which a multi-protocol file server identifies each file with 

1 5 one particular access control model out of a plurality of possible access control models, 
and enforces that particular access control model for all accesses to that file. When the 
file server receives a file server request for that file using a file server protocol with a dif- 
ferent access control model, the file server translates the access control limits imposed by 
the file's access control model into no-less-restrictive access control limits in the differ- 

20 ent access control model. The file server restricts access to the file using the translated 
access control limits. 

Summary of the Invention 

25 The invention provides a method and system for enforcing file access con- 

trol among client devices using multiple diverse access control models and multiple di- 
verse file server protocols. A multi-protocol file server identifies each file with one par- 
ticular access control model out of a plurality of possible models, and enforces that one 
particular model for all accesses to that file. When the file server receives a file server 

30 request for that file using a different access control model, the file server translates the 
access control limits for that file into no-less-restrictive limits in the different model. 
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The file server restricts access by the client device using the translated access control 
limits. 

In a preferred embodiment, each file is assigned the access control model 
5 of the user who created the file or who last set access control limits for the file. When a 
user having a different access control model sets access control limits, the access control 
model for the file is changed to the new model. Files are organized in a tree hierarchy, in 
which each tree is limited to one or more access control models (which can limit the 
ability of users to set access control limits for files in that tree). Each tree can be limited 
10 to NT-model-only format, Unix-model-only format, or mixed NT-or-Unix-models for- 
mat. 

Brief Description of the Drawings 

1 5 The figure shows a block diagram of a system for enforcing diverse access 

control models among client devices. 

Detailed Description of the Preferred Embodiment 

20 In the following description, a preferred embodiment of the invention is 

described with regard to preferred process steps and data structures. However, those 
skilled in the art would recognize, after perusal of this application, that embodiments of 
the invention may be implemented using one or more general purpose processors (or 
special purpose processors adapted to the particular process steps and data structures) op- 

25 erating under program control, and that implementation of the preferred process steps 
and data structures described herein using such equipment would not require undue ex- 
perimentation or further invention. 

Inventions described herein can be used in conjunction with inventions de- 
30 scribed in the following applications: 

4 
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o Application Serial No. 08/985,398. filed December 5, 1997, in the name of An- 
drea Borr, titled "Multi-Protocol Unified File-locking", attorney docket number 
NET-023. 

5 This application is hereby incorporated by reference as if fully set forth 

herein. 

The enclosed technical appendix is part of the disclosure of the invention, 
and is hereby incorporated by reference as if fully set forth herein. 

10 

System Elements 

The figure shows a block diagram of a system for enforcing diverse access 
control models among client devices. 

15 

A system 100 includes a file server 1 10, and a set of client devices 120. 

The file server 1 10 maintains a file system 111, including a set of files 1 12. 

20 In a preferred embodiment, the file server 110 maintains the file system 

111 using inventions described in the following patent applications: 

o Application Serial No. 08/471,218, filed June 5, 1995, in the name of inventors 
David Hitz et al., titled "A Method for Providing Parity in a Raid Sub-System 
25 Using Non- Volatile Memory", attorney docket number NET-004; 

o Application Serial No. 08/454,921, filed May 31, 1995, in the name of inventors 
David Hitz et al., titled "Write Anywhere File-System Layout", attorney docket 
number NET-005; 

30 



5 
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o Application Serial No. 08/464,591, filed May 31, 1995, in the name of inventors 
David Hitz et al., titled "Method for Allocating Files in a File System Integrated 
with a Raid Disk Sub-System", attorney docket number NET-006. 

Each of these applications is hereby incorporated by reference as if fully set 

forth herein. 



The file server 110 is disposed for receiving file server requests 121 from 
the client devices 120. The file server 110 parses each request 121, determines whether 
10 the operation requested in the request 121 is allowed (for the client device 120 that sent 
the request 121 and for the one or more target files 1 12 specified by the request 121). If 
allowed, the file server 1 10 performs that operation on the one or more target files 112. 

The file server 110 is also disposed for transmitting file server responses 
15 122 to the client devices 120. The file server 110 determines the response to each re- 
quest 121 (possibly including a response indicating that the requested operation was not 
allowed), generates that response 122, and transmits that response 122 to the client de- 
vice 120 that sent the request 121. 

20 Each client device 120 is disposed for transmitting file server requests 121 

to the file server 110, and for receiving file server responses 122 from the file server 1 10. 

Access Control Models 

25 In a preferred embodiment, each client device 120 can be either a Unix cli- 

ent device 120 or a Windows NT client device 120. Each client device 120 can either 
use the NFS file server protocol to make requests 121, or use the CIFS file server proto- 
col to make requests 121. (Although typically Unix client devices 120 use the NFS file 
server protocol and NT client devices 120 use the CIFS file server protocol, it is possible 

30 for NT client devices 120 to use the NFS file server protocol by using the PC-NFS im- 
plementation of that file server protocol.) The file server 110 receives each request 121 
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and (if allowed) performs the requested operation on the target files 1 12 specified by the 
request 121. 



The file server 1 10 supports more than one access control model, including 
5 a "Unix Perms" access control model (herein "Unix security style") and an "NT ACL" 
access control model (herein "NT security style"). 

Unix security style uses user IDs (UIDs) to identify users, and group IDs 
(GIDs) to identify groups to which those users belong. Unix security style associates the 
10 following access control limits with each file: 

o a UID for the owner; 

o a GID for the owner; 

15 

o a set of "user" permissions — allowing permission to read, write, or execute the file 
by the owning user; 

o a set of "group" permissions — allowing permission to read, write, or execute the 

20 file by the owning user's group; and 

o a set of "other" permissions — allowing permission to read, write, or execute the 
file by all other users. 

25 Unix security style is supported by the NFS ("Network File System") file 

server protocol, possibly augmented with the NLM ("Network Lock Manager") adjunct 
file-locking protocol. 

NFS is a stateless protocol, so each NFS file server request 121 includes 
30 the UIDs and GIDs of the user making the request. The Unix client device 120 deter- 
mines the UIDs and GIDs for the user at a login time for the user, by reference to the 

system password file (/etc/passwd) and group file (/etc/groups). 

7 
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To enforce file access control using Unix security style, the file server 1 10 
determines if the request 121 is from the owning user, from a user in the owning user's 
group, or from some other user. Responsive to this determination, the file server 1 10 
uses one of the user permissions, the group permissions, or the other permissions, to de- 
5 termine whether to allow the request 121 . 

NT security style uses security IDs (SIDs) to identify both users and 
groups. NT security style associates the following access control limits with each file: 

10 o an SID for the owner; 

o an SID for the owner's group; 

o an ACL (access control list). 

15 

The NT ACL includes one or more ACEs (access control entries), each of 
which includes an SID indicating the user or group to which it applies, and a set of per- 
missions. NT security style provides for the three Unix permissions (read, write, or exe- 
cute), as well as "CHANGE PERMISSIONS" permission, "TAKE OWNERSHIP" per- 
20 mission, "DELETE" permission, "DELETE CHILD" permission, and other permissions. 

NT security style is supported by the CIFS ("Common Internet File Sys- 
tem") protocol. NT security style is further described in the following articles: R. Rei- 
chel, "Inside Windows NT Security", Windows/DOS Developers' Journal (April & May 
25 1993), and in Stephen Sutton, "Windows NT Security Guide" (ISBN 0201419696). 

CIFS is a session-based protocol, so the NT client device 120 transmits the 
NT user name and password to the file server 1 10 at a session connect time, from which 
the SIDs for the user and the user's groups are determined. The file server 1 10 can at- 
30 tempt to authenticate the user itself, or (preferably) forward the NT user name and pass- 
word to an NT primary domain controller. 

8 
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To enforce file access control using NT security style, the file server 110 
determines the SID for the user and the user's group, for the user making the request 121 . 
The file server 1 1 0 accumulates permissions granted to that user from ACEs that apply, 
then subtracts permissions specifically denied to that user. Responsive to this accumula- 
5 tion and subtraction, the file server 1 10 determines whether to allow the request 121 . 

Although a preferred embodiment of the invention is described with regard 
to Unix security style and NT security style, the invention can readily be used with other 
access control models, such as the "POSIX ACL" access control model supported by 

10 some Unix devices, and by some other operating systems. The concepts and features of 
the invention described herein can readily be used in a file server 110 supporting the 
%4 POSIX ACL" access control model in addition to or instead of the access control mod- 
els described in detail herein, without further invention or undue experimentation. Ac- 
cordingly, the scope and spirit of the invention includes such file servers and methods for 

15 their use. 

The file server 110 designates each file 112 maintained in its file system 
1 1 1 as having one specific access control model out of the plurality of access control 
models it supports. In a preferred embodiment, each file 1 12 is designated to use either 
20 Unix security style or NT security style. The file server 1 10 enforces the designated se- 
curity style for each file 1 12 for all attempts to access that file 1 12. Thus, the file server 
110 enforces the designated security style for all requests 121 made for that target file 
112, whether those requests 121 come from Unix devices or NT devices, and whether 
those requests 121 use the NFS file server protocol or the CIFS file server protocol. 

25 

Access Control Enforcement 

If the file server 1 10 receives a request 121 for a target file 1 12, and the re- 
quest 121 matches the security style target file 112, the file server 110 validates the re- 
30 quest 121 against access control limits for that file 1 12 imposed by that security style. 



9 



BNSDOCID: <WO 9945456A1_I_> 



WO 99/45456 PCT/US99/04550 

The file server 110 thus recognizes and enforces at least the following cir- 



cumstances: 



o NT security style. The file 1 12 has NT security style and has a corresponding set 
5 of access control limits (an NT ACL), which has been set by a client device 120 

using the CIFS file server protocol. 

If a client device 120 makes a request 121 to access the file 112 using the 
CIFS file server protocol, the file server 1 10, if it is able to, enforces the NT ACL using 
10 NT security style. 

If the file server 1 10 is able to determine the NT user, either by communi- 
cation with an NT domain controller, or by reference to an NT user SID (security ID) 
database, the file server 1 10 is able to enforce the NT ACL using NT security style. 

15 

If the file server 1 10 is not able to determine the NT user, it determines the 
equivalent Unix user, using a UID for a Unix user recorded for the CIFS file server pro- 
tocol session, and enforces the NT ACL as if the request 121 came from that Unix user. 

20 ° Unix security stvle. The file 1 12 has Unix security style and has a corresponding 
set of access control limits (Unix Perms), which have been set by a client device 
120 using the NFS file server protocol 

If a client device 120 makes a request 121 to access the file 112 using the 
25 NFS file server protocol, the file server 110 enforces the Unix Perms using Unix security 
style. 



However, the file server 110 can also receive a request 121 that does not 

match the security style for the target file 112. The file server 1 10 can enforce the secu- 

30 rity style for the target file 112 against a non-matching client device 120 by validating 

either (1) a translated user ID for the client device 120 or (2) a translated set of access 

control limits for that file 1 12. As described herein, the file server 1 10 validates trans- 

10 
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lated user IDs for all Unix security style files 112, and preferably validates translated 
user IDs for NT security style files 1 12 (when possible). Moreover, when the file server 
1 10 validates translated access control limits for the file 1 12, the translated access control 
limits are not recomputed for each request 121, but are cached with the file 1 12 for reuse. 

5 

The file server 1 10 thus also recognizes and enforces at least the following 
circumstances: 

o NT security style. The file 1 12 has NT security style and has a corresponding set 
10 of access control limits (an NT ACL), which has been set by a client device 120 

using the CIFS file server protocol. 

If a client device 120 makes a request 121 to access the file 1 12 using the 
NFS file server protocol, the file server 1 10 determines the Unix user, associated with the 
1 5 client device 120, that is making the request 121 . The Unix user has a UID (user ID). 

In a preferred embodiment, the file server 110 maps the Unix user into an 
equivalent NT user. The file server 1 10 translates the UID into an SID (security ID) that 
is an equivalent user to the Unix user. The file server 110 enforces the access control 
20 limits (the NT ACL) for the equivalent NT user (the SID). 

The file server 110 performs the following process to map the Unix user 
into an equivalent NT user: 

25 o The client device 120 contacts the file server 1 10 using the NFS file server proto- 
col. The NFS file server protocol request 121 includes a UID for the Unix user 
associated with the client device 120. 

o The file server 1 10 looks up the UID in the Unix password file (/etc/passwd), and 
30 thus identifies the Unix user name for the Unix user. The Unix user name is an 

alphanumeric string identifying the Unix user. 

11 
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o The file server 1 10 translates the Unix user name into an NT user name using a 
selected mapping file. Similar to the Unix user name, the NT user name is an al- 
phanumeric string identifying the NT user. If there is no such translation for the 
Unix user name, the file server 110 uses the Unix user name, without translation, 
5 as the NT user name. 

In a preferred embodiment, the mapping file includes a set of records each identi- 
fying an NT user by NT user name, and associating an equivalent Unix user name 
with the NT user name. 

10 

o The file server 1 10 contacts an NT domain controller to determine an SID for the 
NT user name. If there is no such NT user, the file server 1 10 uses a selected pa- 
rameter for unmapped Unix users. In a preferred embodiment, this selected pa- 
rameter is set to the NT user "guest" ' by default. 

15 

o The file server 110 contacts the NT domain controller to obtain the SIDs of all 
groups for which the NT user is a member. 

The file server 1 10 caches UID-to-SID mappings for a period of time, pref- 
20 erably about a few hours. 

In an alternative preferred embodiment, or if the file server 1 10 is unable to 
map Unix users to NT users (for example, if domain authentication has been turned off), 
the file server 1 10 maps the NT ACL into a no less restrictive set of Unix Perms. The 
25 file server 1 10 determines these Unix Perms in response to the NT ACL and in response 
to the Unix user. The file server 110 enforces the mapped access control limits (the Unix 
Perms) for the actual Unix user (the UID). 

The file server 110 might perform dynamic permission mapping, in which 

30 the file server 110 maps the NT ACL into a set of Unix Perms at the time the mapping is 

required. In a preferred embodiment, the file server 110 caches the translated Unix 

Perms with the file 1 12. Accordingly, for validating access control limits, the file server 

12 
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1 10 performs static permission mapping, in which the file server 1 10 maps the NT ACL 
into a set of Unix Perms at the time the NT ACL is set. 



The file server 110 performs the following process to achieve static per- 
5 mission mapping: 

o The file server 110 determines the NT user that is the owner of the file 1 12, and 
maps the NT user into an equivalent Unix user (the file server 1 10 maps the SID 
for the NT user into a UID for a Unix user). 

10 

o The file server 1 10 examines the NT ACL for the file 1 12 and determines whether 
there are any "deny access" provisions. 

o If the NT ACL for the file 1 12 has no "deny access" provisions, the file server 1 10 
15 generates a set of Unix Perms having an entry for "user permissions," consistent 

with the file access control limits provided by the NT ACL. The file server 1 10 
sets the Unix Perms for "group permissions" equal to the Unix Perms for "other 
permissions." The file server 110 sets the Unix Perms for "other permissions" 
equal to the NT ACL entry for "everyone," if one exists. 

20 

o If the NT ACL for the file 1 12 does have "deny access" provisions, the file server 
1 10 rejects the request 121. 

Because static permission mapping is not responsive to the particular user 
25 making the request 121, the file server 1 10 does not attempt to determine what the provi- 
sions of the NT ACL are for that particular user. 

o Unix security style. The file 1 12 has Unix security style and has a corresponding 
set of access control limits (Unix Perms), which have been set by a client device 
30 120 using the NFS file server protocol 



13 
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If a client device 120 makes a request 121 to access the file 1 12 using the 
CIFS file server protocol, the file server 1 10 determines the NT user, associated with the 
client device 120, that is making the request 121. The NT user has an SID (session ID). 

5 The file server 110 maps the NT user into an equivalent Unix user. The 

file server 110 translates the SID into a IJID that is an equivalent user to the NT user. 
The file server 1 10 enforces the access control limits (the Unix Perms) for the equivalent 
Unix user (the UID). 



10 



The file server 1 10 performs the following process to map the NT user into 
an equivalent Unix user: 



o The client device 120 starts a CIFS session (the client device 120 first contacts the 
file server 1 10 using the CIFS file server protocol). The client device 120 trans- 
15 mits its NT user name to the file server 110. 

o The file server 110 translates the NT user name into a Unix user name using a 
mapping file. If there is no such translation for the NT user name, the file server 
1 10 uses the NT user name, without translation, as the Unix user name. 

20 

o The file server 110 looks up the Unix user name in the Unix password file 
(/etc/passwd), and thus identifies the Unix user, the UID for the Unix user, the 
Unix user's primary group, and the primary GID (group ID) for the Unix user. If 
there is no such Unix user name in the Unix password file, the file server 1 10 uses 
25 a selected parameter for unmapped NT users. In a preferred embodiment, this se- 

lected parameter is set to the Unix user "nobody" by default. 

o The file server 110 looks up the Unix user name in the Unix group file 
(/etc/groups) to determine any other groups and any other GIDs associated with 
30 the Unix user. 
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Each file 112 has its security style set by the file server 110 so that either 
(a) a request 121 to perform an operation on the file 1 12, or (b) a request 121 to perform 
5 an operation that sets the access control limits for the file 1 12, produce expected results. 

When the file 1 12 is first created, the file server 1 10 sets the security style 
for the file 1 12 equal to a security style associated with the file server protocol used to 
create it. (This is limited by restrictions imposed by access control trees, described 
10 herein.) Thus, if the file 112 is created using the NFS file server protocol, the security 
style for the file 1 12 is set to Unix security style. Similarly, if the file 1 12 is created us- 
ing the CIFS file server protocol, the security style for the file 1 12 is set to NT security 
style. 

15 When the file 1 12 has its access control limits modified, the file server 1 10 

sets the security style for the file 1 12 equal to a security style associated with the new ac- 
cess control limits. (This is limited by restrictions imposed by access control trees, de- 
scribed herein.) Thus, if a client device 120 sets a set of Unix Perms for the file 1 12, the 
security style for the file 112 is set to Unix security style. Similarly, if a client device 

20 120 sets an NT ACL for the file 1 12, the security style for the file 1 12 is set to NT secu- 
rity style. 

The file server 110 can receive a request 121 to read or view the access 
control limits for a file 112. Also, when the file server 110 receives a request 121 to 
25 make an incremental change to the access control limits for a file 112, it determines the 
current access control limits for the file 112 before making the incremental change. 

The file server 1 10 thus recognizes and enforces at least the following cir- 
cumstances: 

30 
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o NT security style. The file 1 12 has NT security style and has a corresponding set 
of access control limits (an NT ACL), which has been set by a client device 120 
using the CIFS file server protocol. 

5 If a client device 120 makes a request 121 to read or modify the access 

control limits for the file 1 12 using the NFS file server protocol, the file server 110 de- 
termines the Unix user, associated with the client device 120, that is making the request 
121. 

10 The file server 110 performs the same process to map an NT ACL into a 

set of Unix Perms as described above for validation of file access control, with the fol- 
lowing exceptions: 

Unlike validation of access control limits, the file server 110 treats transla- 
15 tion of access control limits differently for requests 121 to read or modify the access 
control limits for the file 112. 

Preferably, the file server 110 performs dynamic permission mapping, in 
which the file server 1 10 maps the NT ACL into a set of Unix Perms at the time the 

20 mapping is required. NT security style is richer than Unix security style — for example, 
Unix security style has no "deny access" provisions. Thus, it is possible for the file 
server 1 10 to map the NT ACL into a set of Unix Perms that appears different for differ- 
ent Unix users. For example, if the NT ACL, for a file 1 12 whose owner is Charles, spe- 
cifically provides read access to Allen but specifically denies read access to Beth, the file 

25 server 110 will provide different Unix perms to each of the users Allen and Beth. One 
set will allow read access by Allen's group and one set will disallow read access by 
Beth's group, in harmony with the access provided by the actual NT ACL. 

The file server 110 performs the following process to achieve dynamic 
30 permission mapping: 
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The file server 1 10 determines the NT user that is the owner of the file 1 12, and 
maps the NT user into an equivalent Unix user (the file server 1 10 maps the SID 
for the NT user into a UID for a Unix user). 

The file server 1 10 examines the NT ACL for the file 1 12 and determines whether 
there are any "deny access" provisions. 

If the NT ACL for the file 1 12 has no "deny access" provisions, the file server 1 10 
generates a set of Unix Perms having entries for "user permissions" and "other 
permissions," consistent with the file access control limits provided by the NT 
ACL. The file server 1 10 sets the Unix Perms for "group permissions" equal to 
the Unix Perms for "other permissions." 



o 

10 



o If the NT ACL for the file 1 12 does have "deny access" provisions, the file server 
15 110 attempts to determine if any apply to the particular Unix user. If the file 

server can tell, it generates a set of Unix Perms that reflect the access control lim- 
its currently available for this particular file 112 and this particular Unix user. If 
the file server 110 cannot tell, it rejects the request 121. (Alternatively, the file 
server 1 10 could reject the request 121 if there are any "deny access" provisions in 
20 the NT ACL.) 



25 



30 



In alternative embodiments, the file server 110 may perform static permis- 
sion checking, similar to validation of access control limits, for requests 121 to read or 
modify the access control limits for the file 1 12. 

If the request 121 attempts to modify attributes of the file 1 12 that have no 
effect on access control limits for the file 112 (such as access time or modify time), the 
file server 1 10 makes those modifications without change to the access control limits for 
the file 112. 

If the request 121 attempts to modify some but not all access control limits 

for the file 1 12, the file server 1 10 generates a set of Unix Perms in response to the NT 
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ACL for the file 112, as described above. The file server 110 modifies the generated 
Unix Perms as specified by the request 121. If the file server 110 cannot generate a set 
of Unix Perms in response to the NT ACL for the file 1 12, the file server 1 10 rejects the 
request 121. 

5 

One difference in setting access control limits is that, according to NT se- 
curity style, files 1 12 can be specifically set to be "READ-ONLY." According to Unix 
security style, files are set to be read only by clearing the WRITE permission for the 
owner of the file 1 12. When a client device 120 using the CIFS file server protocol at- 
10 tempts to set the READ-ONLY attribute of a file 1 12 with Unix security style, the file 
server 1 10 clears the WRITE permission for the owner of the file 1 12 in the Unix Perms 
for that file 112. 

Unix security stvle. The file 112 has Unix security style and has a corresponding 
set of access control limits (Unix Perms), which have been set by a client device 
120 using the NFS file server protocol 

The file server 110 performs the following process to map a set of Unix 
Perms into an NT ACL for display or modification of those Unix Perms by a CIFS client 
20 device 120: 

o The file server 1 10 generates an NT ACL entry for "owner," providing the same 
access control limits as the Unix Perms entry for "user permissions." 

25 o The file server 110 generates an NT ACL entry for "everyone," providing the 
same access control limits as the Unix Perms entry for "other permissions." 

o If possible, the file server 110 generates an NT ACL entry for the actual request- 
ing user, providing the same access control limits as the Unix Perms entry for that 
30 user. This step could require mapping the Unix user into an equivalent NT user 

using the UID-to-SID cache. 
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Similar to modification of an NT ACL entry by a Unix user, if the request 
121 (for modification of Unix Perms by an NT user) attempts to modify attributes of the 
file 112 that have no effect on access control limits for the file 112, the file server 110 
makes those modifications without change to the access control limits for the file 1 12. 

5 

If the request 121 attempts to modify some but not all access control limits 
for the file 1 12, the file server 1 10 generates an NT ACL in response to the set of Unix 
Perms for the file 112, as described above. The file server 1 10 modifies the generated 
NT ACL as specified by the request 121. 

10 

Access Control Subtrees 

In a preferred embodiment, the files 112 in the file system 1 1 1 are organ- 
ized into a tree, having a set of branch nodes and a set of leaf nodes. One branch node of 
15 the tree is a root node, and each branch node of the tree is a root node for a subtree of the 
tree. In the file system 111, each branch node is a directory, and each leaf node is a file 
112. A directory is a type of file 1 12 that includes information about those branch nodes 
and leaf nodes in a subtree for which it is the root node. 

20 The file server 1 10 associates a limited set of access control models with 

each subtree. In a preferred embodiment in which the file server 1 10 supports Unix secu- 
rity style and NT security style, the file server 1 10 designates each subtree as being NT- 
only format, Unix-only format, or mixed format. 

25 NT-only Format 

When the file server 110 designates a subtree as being NT-only format, it 
restricts creation of files 112 within that subtree to files 112 having NT security style. 
The file server 110 also prohibits changing the access control model of files 1 12 within 
30 that subtree to other than NT security style. 
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According to NT security style, new files 112 inherit NT ACL settings 
from their parent nodes. If a client device 120 using the NFS file server protocol at- 
tempts to create a file 1 12 in a subtree having NT-only format, that file 1 12 can only be 
created by the Unix user equivalent to the NT user who is the NT-owner of the root node 
5 of the subtree. The file server 110 determines if the Unix user making the request 121 is 
the equivalent by (a) mapping the SID for the NT user who is the owner into an equiva- 
lent UID; (b) storing that UID in its record for the file 1 12; and (c) comparing that UID 
with the UID in the request 121. 

10 According to NT security style, there is a particular "DELETE" permission 

and a particular "DELETE-CHILD" permission. If the file server 110 is unable to de- 
termine if a Unix user has these permissions, it rejects requests 121 to delete files 1 12 in 
NT-only format subtrees, unless the request 121 is from the owner of the file 112 (the 
equivalent Unix user of the NT user who is the owner) or the Unix user "root". 

15 

According to NT security style, there is a particular "CHANGE- 
PERMISSION" permission and a particular "TAKE-OWNER" permission. If the file 
server 1 10 is unable to determine if a Unix user has these permissions, it denies requests 
121 to set any permissions for files 112 in a NT-only format subtree, unless the request 
20 121 is from the owner of the file 1 12 (the equivalent Unix user of the NT user who is the 
owner) or the Unix user "root". 

Unix-only Format 

25 Similarly, when the file server 1 10 designates a subtree as being Unix-only 

format, it restricts creation of files 1 1 1 within that subtree to files 1 1 1 having Unix secu- 
rity style. The file server 110 also prohibits changing the access control model of files 
1 1 1 within that subtree to other than Unix security style. Attempts to set an NT ACL 
would change the access control model for that file 112 to NT security style, and so are 

30 rejected in a Unix-only format subtree. 
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When a client device 120 using the CIFS file server protocol creates a file 
1 12 in a Unix-only format subtree, the file server 1 10 sets the owner of the file 112 to the 
Unix user equivalent to the NT user making the request 121. The file server 110 maps 
the SID for the NT user to a UID for an equivalent Unix user, and uses that UID to set 
5 the owner of the file 1 12. 

According to Unix security style, there is no "CHANGE-PERMISSION" 
permission or "TAKE-OWNER" permission. The file server 110 always denies requests 
121 to set these permissions for files 1 12 in a Unix-only format subtree. 

10 

Mixed Format 

When the file server 1 10 designates a subtree as being mixed format, it al- 
lows creation of files 1 1 1 with either Unix security style or NT security style. The file 
15 server 1 10 does not prohibit changing the access control model of files 111 within that 
subtree to either Unix security style or NT security style. 

An administrator for the file server 110 can change the designation of a 
subtree from a first format to a second format (for example, from mixed format to either 

20 NT-only format or Unix-only format). When the second format is possibly incompatible 
with the first format (for example, a subtree changed to NT-only format includes nodes 
that are Unix security style), the file server 1 10 converts those files 1 12 with incompati- 
ble access control models as it sets permissions for those files 112. Requests 121 for a 
file 1 12 which only check permissions are still validated using the access control model 

25 in place for the file 1 12. 

Although the invention is described herein with regard to only two access 
control models, the invention can readily be used with three or more access control mod- 
els. In such alternative embodiments, there are a larger number of possible subtree for- 
30 mats, including subtree formats that restrict the files 1 12 within that subtree to one of a 
set of multiple access control models, less than the set of all access control models rec- 
ognized by the file server 110. 
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In a preferred embodiment, the root node of the file system 1 1 1 is desig- 
nated as having mixed format. Client devices 120 that are owners of a subtree can mod- 
ify the format of a subtree by request 121 to the file server 110; thus, client devices 120 
can modify subtrees to have NT-only format, Unix-only format, mixed format. When a 
new subtree is created, the file server 110 designates the new subtree as having the same 
format as its parent; thus, mixed format if it is created within a subtree that is already 
mixed format (the default), NT-only format if it is created within a subtree that is already 
NT-only format, and Unix-only format if it is created within a subtree that is already 
Unix-only format. 

Alternative Embodiments 



Although preferred embodiments are disclosed herein, many variations are 
possible which remain within the concept, scope, and spirit of the invention, and these 
15 variations would become clear to those skilled in the art after perusal of this application. 
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Claims 

1 . A method of operating a file server, said method including steps for 
identifying a first file on said file server with a first security style selected 

5 from among a plurality of security styles; and 

enforcing said first security style for all accesses to said first file. 

2. A method as in claim 1, wherein said plurality of security styles in- 
cludes a Windows NT security style. 

10 

3. A method as in claim 1, wherein said plurality of security styles in- 
cludes a Unix security style. 

4. A method as in claim 1, including steps for 
associating said first file with a subset of files in a file system; and 
limiting said subset of files to a security subset of said plurality of security 

styles; 

wherein attempts to set permissions in said file system tree are restricted to 
said security subset. 

5. A method as in claim 4 ? wherein said security subset includes a 
Windows NT security style. 

6. A method as in claim 4, wherein said security subset includes a Unix 
25 security style. 

7. A method as in claim 1, including steps for identifying said first file 
with a second security style in response to a file server request. 

30 8. A method as in claim 7, including steps for associating said second 

security style with a file server request for setting permissions for said first file when said 
file server request is successful. 

23 
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9. A method as in claim 7, wherein said steps for identifying include 
steps for translating a first set of permissions associated with said first file in said first 
security style to a second set of permissions in said second security style, wherein said 
second set of permissions is no less restrictive than said first set of permissions. 

10. A method as in claim 1, wherein said steps for enforcing include 

steps for 

recognizing a first set of permissions associated with said first file in said 
first security style; 

defining a first user type associated with said first security style; 

translating a user from a second user type associated with a second security 
style into said first user type; and 

enforcing a file server request from said second user type using said first 
user type and said first set of permissions. 

11. A method as in claim 10, wherein said steps for translating are per- 
formed with regard to access control limits applicable to said first file at a time of said 
steps for enforcing. 



20 12. A method as in claim 10, wherein said steps for translating are per- 

formed with regard to access control limits applicable to said first file at a time said ac- 
cess control limits are set. 

13. A method as in claim 1, wherein said steps for enforcing include 

25 steps for 

translating a first set of permissions associated with said first file in said 
first security style to a second set of permissions in a second security style, wherein said 
second set of permissions is no less restrictive than said first set of permissions; and 

enforcing a file server request in said second security style using said sec- 
30 ond set of permissions. 



15 
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14. A method as in claim 13, wherein said steps for translating are per- 
formed with regard to access control limits applicable to said first file at a time of said 
steps for enforcing. 

15. A method as in claim 13, wherein said steps for translating are per- 
formed with regard to access control limits applicable to said first file at a time said ac- 
cess control limits are set. 



16. A file server including 

!0 a set of files available said file server, each said file having an associated 

security style selected from among a plurality of security styles available on said file 
server; 

wherein said file server enforces said associated security style for all ac- 
cesses to said file. 

15 

17. A file server as in claim 16, wherein said plurality of security styles 
includes a Windows NT security style. 



18. A file server as in claim 16, wherein said plurality of security styles 
20 includes a Unix security style. 



19. A file server as in claim 16, including 

a subtree of files in said file system associated with a security subset of said 
plurality of security styles; 
25 wherein said file server restricts attempts to set permissions in said subtree 

to said security subset. 

20. A file server as in claim 19, wherein said security subset includes a 
Windows NT security style. 

30 

21. A file server as in claim 19, wherein said security subset includes a 
Unix security style. 
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22. A file server as in claim 16, wherein said file server is capable of 
altering the security style associated with said file in response to a file server request. 

23. A file server as in claim 22, wherein said file server is capable of 
5 altering the security style associated with said file in response to a file server request 

when said file server request is successful. 

24. A file server as in claim 22, wherein said file server is capable of 
translating a first set of permissions associated with said file in a first security style to a 
second set of permissions in a second security style, wherein said second set of permis- 
sions is no less restrictive than said first set of permissions. 



10 



25. In a file server having a plurality of files, a data structure associating 
a security style with each said file, said security style being selected from among a plu- 

15 rality of security styles available on said file server. 

26. A data structure as in claim 25, wherein said plurality of security 
styles includes a Windows NT security style. 



20 



30 



27. A data structure as in claim 25, wherein said plurality of security 
styles includes a Unix security style. 



28. In a file server having a plurality of files and a security style associ- 
ated with each said file, said security style being selected from among a plurality of secu- 

25 rity styles available on said file server, a data structure associating a security subset of 
said plurality of security styles with a subtree of said files available on said file server. 

29. A data structure as in claim 28, wherein said security subset includes 
a Windows NT security style. 



30. A data structure as in claim 28, wherein said security subset includes 
a Unix security style. 
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AMENDED CLAIMS 
[received by the International Bureau on 13 September 1999 (13.09.99); 
original claims 1 -30 replaced by amended claims 1 -32 (6 pages)] 

1 . A method of operating a file server, said method including 

steps for 

identifying a first file on said file server with a first security style 
selected from among a plurality of security styles; and 

enforcing said first security style for all accesses to the first file 
regardless of the security style associated with the entity who seeks access to the 
first file. 



2. A method as in claim 1, wherein, said plurality of security 
styles includes a Windows NT security style. 

3. A method as in claim 1, wherein said plurality of security 
styles includes a UNIX security style. 

4. A method as in claim 1, including the steps for 
associating said first file with a subset of files in a file system; 
limiting said subset of files to a security subset of said plurality of 

security styles; and 

caching the associations and limits for those files for future use; 

wherein attempts to set permission in said file system tree are 
restricted to said security subset. 

5. A method as in claim 4, wherein said security subset includes 
a Windows NT security style. 
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6. A method as in claim 4, wherein said security subset includes 
a UNIX security style. 

7. A method as in claim 4, wherein the steps of associating and 
limiting can be performed dynamically (associated with a specific attempt to 
access an object) or statically (not associated with a user or specific attempt to 
access an object). 



8. A method as in claim 1 including steps for 
identifying said first file with a second security style in response to a 
file server request regardless of the security style associated with the first file. 



9. A method as in claim 8, including steps for 
associating said second security style with a file server request for 

setting permissions for said first file when said file server request is successful. 

10. A method as in claim 8, wherein steps for identifying include 
steps for translating a first set of permissions associated with said first file in said 
first security style to a second set of permissions in a second security styles, 
wherein said second set of permissions is no less restrictive than said first set of 
permissions. 



11. A method as in claim 8, wherein the step of translating 
includes mapping NT access control limits into a no less restrictive set of UNIX 
Perms. 



12. A method as in claim 8, wherein the step of translating 
includes mapping a set of Unix Perms into a set of no less restrictive NT access 
control limits. 
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13. A method as in claim 1, wherein said steps for enforcing 
included steps for dynamically 

recognizing a first set of permissions associated with said first file in 
said first security style; 

defining a first user type associated with said first security style 

translating a user from a second user type associated with a second 
security style into said first user type; 

caching the translation; and 

enforcing a file server request from said second user type using said 
first use type and said first set of permissions. 

14. A method as in claim 13, wherein steps for recognizing, 
defining, translating and caching can be performed statically, either at a time of 
said access control limits are set or reset. 

15. A method as in claim 1, wherein said steps for enforcing 
include steps for 

translating a first set of permissions associated with said first file in 
said first security style to a second set of permissions in a second security style, 
wherein said second set of permissions is no less restrictive than said first set of 
permissions; 

caching the translation; and 

enforcing a file server request in said second security style using said 
second set of permissions. 

16. A method as in claim 15, wherein said steps for translating are 
performed dynamically and occur approximately when the steps of enforcing take 
place. 
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17. A method as in claim 15 , wherein said steps for translating are 
performed statically and occur approximately when said access control limits are 
set or reset. 



18. A file server including 

a set of files available to said file server, each file having an 
associated security style selected from among a plurality of security styles 
available on said file server; 

wherein said file server enforces said associated security style 
for all accesses to said file. 



19. A file server as in claim 1 8, wherein plurality of securities 
styles includes a Window's NT security style. 



20. A file server as in claim 18, wherein plurality of security styles 
includes a UNIX security style. 

21. A file server as in claim 1 8, including 

a subtree in said file system associated with a security subset of said 
plurality of security styles; 

wherein said file server restricts attempts to set permissions in said 
subtree to said security subset. 

22. A file server as in claim 21, wherein said security subset 
includes a Windows NT security style. 
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23. A file server as in claim 21, wherein said security subset 
includes a UNIX security style. 

24. A file server as in claim 18, wherein said file server is capable 
of altering the security style associated with said file in response to a file server 
request. 

25. A file server as in claim 24, wherein said file server is capable 
of altering the security style associated with said file in response to a file server 
request when said file server request is successful. 

26. A file server as in claim 24, wherein said file server is capable 
of translating a first set of permissions associated with said file in a first security 
style to a second set of permissions in a second security style, wherein said second 
set of permissions is no less restrictive than said first set of permissions. 

27. In a file server having a plurality of files, a data structure 
associating a security style with each said file, said security style being selected 
from among a plurality of security styles available on said file server. 

28. A data structure as in claim 27, wherein said plurality of 
security styles includes a Windows NT style. 

29. A data structure as in claim 27, wherein said plurality of 
seucrity styles includes a UNIX security style. 

30. In a file server having a plurality of files and a security style 
associated with each file, said security style being selected from among a plurality 
of security styles available on said file server, a data structure associating a 
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security subset of said plurality of security styles with a subtree of said files 
available on said file server. 

31. A data structure as in claim 30, wherein said security subset 
includes a Windows NT security style. 

32. A data structure as in claim 30 wherein security subset 
includes UNIX security style. 
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STATEMENT UNDER ARTICLE 19 



Application believes the amendments to the claims do not make any impact 
on the description or the drawing. 

The invention includes a highly reliable and efficient system and method 
for providing access control using a multi-protocol file server. 

Montague (US 5,675,782) discloses a method and system for controlling 
access to entities on a network. Montague teaches how a file server can limit 
access of a plurality of entities variously controlled by Windows NT and or 
Novell's NETWARE. Montague's method involves identifying the user and the 
operating system, determining whether the user has access to a file and translating 
an access control option for Novell's network into one for Windows NT. 

Unlike Montague, the invention applies to entities on a network that are 
controlled by Windows NT or UNIX security styles. Instead of translating an 
access control option for Novell into one for Windows NT, the invention translates 
NT access controls into Unix access controls by dynamically mapping the NT 
permission access control limits into a no less restrictive set of UNIX Perms. The 
reverse translation is also possible, as is static mapping (that is, mapping that is not 
responsive to a particular user). Moreover, unlike Montague, the invention 
provides for caching the mapped permissions for future use. 
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